Aminet 25/Aminet 25 (1998)(GTI - Schatztruhe)[!][Jun 1998].iso/Aminet/dev/basic/UDP_Chat.lha/UDPTest/UDP-Examples.readme

Text File | 1998-04-23 | 7.5 KB | 166 lines

                         UDP Examples

 Written by Anton Reinauer- 23/4/98

     These examples are useful for anyone who wants to write a internet
multi-user, fast reaction game (platformers, Doom clones etc), that by
their nature must have small communication delays (lags). These
programs differ from Paul Burkey's TCP examples in that they use the
UDP internet protocol instead of TCP for speed (TCP is ok for strategy
or turn based games as a slight lag is acceptable with them). UDP is
much faster, but unlike TCP there is no guarantee that your data packet
will get to it's destination (UDP is about 90% reliable); so you have
to write your communication code with this in mind.

     You need TCP-to-Blitz.lha from dev/basic on Aminet, and recompile
your Deflibs with bsdsocket.library1 in your amigalibs drawer in
Blitzlibs: . You'll obviously need an TCP/IP stack like Miami or AmiTCP
running (an Internet connection isn't necessary if you're just running
it locally).

   Minumum requirement: an A500 with some extra fast mem (to run the
TCP/IP stack in), and WB 2.0+. You have to turn overflow errors off in
the debugger options in Compiler Options.

   All four programs open UDP sockets (domain AF_INET, and type of
SOCK_DRAM). The first Send program (UDP_Send) just simply sends each
packet to the host address and port defined at the top of the program
(this could be different for every data packet). UDP_Receive binds it's
socket with bind_() to localhost at the port defined at the top of the
program (this port can't have an entry in Services though). Then it
just checks if any data is waiting on the socket and gets it.

   The second Send program (UDP_Send2) does things slightly
differently. It opens a socket and then does a connect_() to the port
on the appropriate host (defined at the top of the program). Then it
just uses send_() like in TCP, and all packets will be sent to the
connected socket. UDP_Receive2 does the same as UDP_Receive, and binds
the socket to the port, but because there's a TCP-like connection to
the sending host, it just uses recv_() to receive data.

   Just run UDP_Send and UDP_Receive (or UDP_Send2 and UDP_Receive2),
and type some letters into the Send window and hit return, and they
will appear in the receive window. To close the programs, hit the close
button in their window. Note: UDP_Send works with UDP_Receive2, and
vice-versa!

   I haven't got the programs working as a Daemon yet- when I tried, it
opened three programs for every packet sent (and AmiTCP said it had got
into a loop)! It appears UDP works slightly differently than TCP, I
think your Daemon has to signal back to the TCP/IP stack that it's
running or something. I don't think you'll really need a UDP Daemon
anyhow, as you'll probably being doing peer-to-peer connections, rather
than using a Server. You could always use a small TCP Daemon, which puts
up a window, to ask the user if they want to play a game, which could
then run your game and exit.

   UDP_Chat is a simple IRC chat type program using UDP. The code is a
bit messy at the moment (and I've added some horrible hacks to Alvaro
Thompson's (once) nice font sensitive code :-) - Typical bloody games
programmer ;-) . I have to write more docs for it, but you should be
able to work out what it's doing. I've written it as a game
communication code test program.

   You have to have a TCP/IP stack running before you run UDP_Chat.
Your host address is printed beside the Localhost button. You have to
give this address to the other person through IRC (and vice-versa), and
then you type the address they give you in the Send To: gadget and hit
return. You shouldn't have to change the port number gadget (unless
you've got two of them running locally- the second one will be bound to
a port number one number higher than the first- the port UDP_Chat is
bound to is printed up in the top-right corner).

  The lastest version (V1.9), has the UDP_Funcs in a separate Include
(and have a bugfix in them). It checks wether packets have arrived at
their destination and resends them if they haven't (ie: no reply after a
certain time- 5 secs). After 5 resends it assumes the link is dead and the
player is considered offline- it doesn't do it properly at the moment- it
needs bugfixing. It doesn't show the ping time for each player yet, only the
time for the last packet.
  It can act as a Server or a Client- if it receives a correct connection
request, it becomes the Server, and can have up to 7 other players
online. If it logs into another program (that isn't already online as a
client, and has a spare player position) it will be logged in as a Client
- note it will still send messages directly to all the other players, not
through the Server.
  See above for logging into another UDP_Chat program. You can run up to
8 UDP_Chat programs locally for testing, and all can log into one acting
as a Server- they all get different port numbers.
  Then just type into the Send: gadget and hit return. Your words will
be echoed on the screen above and will be sent to any players online.
If you can't connect to a host (it will tell you under the
Send To: gadget), you won't have your words echoed onscreen, and they
won't be sent. The numbers after R: and S: (received and sent), are
packet number, and the player the packet is sent or received from.
  The Delay 1s button stops the program for 1 second, and the Delay 1m
stops the program for 1 minute- this is for simulating lags or lost
links. The localhost button is for getting your local IP address if
you go online after you've started the program.

  The Net Protocol Header defines the hex numbers that tell what each
packet is, so you can decode the data in each packet. I haven't fully
documented the protocol on computer file yet, but it's pretty
self-explanatory.
  You'll notice I've put in some security measures, ie: it checks if the
packet has come from a logged-in host (rather than having a player number
in the packet- saves data too), so it stops people sending fake messages
to try and cheat. People could still send fake IP packets if they knew what
they were doing, so I might put in a security number in each packet, that
is random for each connection between each of the players. Even basic
encryption might be needed as well.

  It needs to have code put in for disconnecting, to tell the Server which
will then inform the other players. Also each player needs to send out
a `heartbeat' if they haven't send a packet for 5 seconds, so other players
know they're still online. The numbered buttons are to check the lag to
each player- not implemented yet.

   See Paul Burkey's Net web page for more info on Internet game
connections: <http://www.sneech.demon.co.uk/netlink.html>
   Also see the file included in this archive `Lag problems in Net games',
it is a discussion from the Blitz-List on the problems caused by lags
in multiplayer games, and a couple of solutions to those problems.

   Feel free to use these routines in your program; just give me and
Paul Burkey a mention in your credits :-)  And maybe a copy of your game
if you think these routines are worth it :-)

Thanks to Paul Burkey for TCP_Funcs.

        <[e-mail]>

        <[e-mail]>

        <http://www.sneech.demon.co.uk>



Alvaro Thompson for TCP_GUI

        <[e-mail]>



and to Dr. Ercole Spiteri for TCP-to-Blitz.

        <[e-mail]>

        <[e-mail]>



Any questions/comments to:

        Anton Reinauer   <[e-mail]>

        <http://www.ww.co.nz/home/anton>